三十天走完了

從 Day 1 的「為什麼資安需要垂直模型」，到昨天的「模型可換，治理不變」。今天做三件事：如果重來的順序、哪些部分可復現、以及這件事真正教了我什麼。

如果重來，我會換掉的順序

我實際的順序是：定位 → 資料 → 訓練 → Agent → 治理。

如果重來，我會這樣走：

1. 定位與場景        （原 Day 1–2，不變）
2. 治理層設計 ★      （原 Day 24–28，大幅提前）
3. 資料脈絡層 ★      （原 Day 15–23 的前處理部分，提前）
4. 用現成模型跑通全流程 ★  （新增，原本沒有）
5. 建立任務導向評測 ★ （原 Day 14，大幅提前）
6. 才開始微調        （原 Day 3–13，往後移）
7. 用評測驗證微調是否值得

四個 ★ 是主要的改動。理由：

★ 治理層提前：因為它決定了系統長什麼樣。狀態機、審核流程、稽核軌跡如果最後才加，會發現前面的設計不支援，要改一大堆。而且這一層的思考不需要模型就能做。

★ 資料脈絡層提前：因為它是護城河（Day 29），而且它的價值會複利——越早開始累積客戶脈絡、越早開始記錄修改分類，三個月後的資產差距越大。

★ 先用現成模型跑通全流程：這是最大的改動。我應該先用一個現成的模型，把四個任務的流程完整跑通，讓真正的使用者用一段時間。

這樣做的話，我在動任何訓練之前就會知道：哪些任務真的需要微調（月報）、哪些其實 RAG 就夠（顧問問答）、審核者實際上都在改什麼。

而我實際上是先訓練了兩週，才發現這些。

★ 評測提前：如果我在訓練前就建好了 Day 14 那四類任務導向指標，我就不會拿多選題 benchmark 當唯一標準，也不會有 Day 12 那個令人困惑的結果。

歸納成一句話：我把「可以先做、而且不需要模型的事」，放到了模型後面。

哪些部分是可復現的

這個系列有一部分東西是綁在我的場景與資料上的，但有相當比例是通用的。

完全可復現（不依賴我的資料）：

• Day 6 的資料分流判準——會過期／要引用／要準確 → RAG；要內化／是風格 → 訓練
• Day 8 的記憶體預算算法——每參數 12 bytes 的估算法與四塊拆解
• Day 14 的四類任務導向評測——格式一致性、事實回溯率、審核通過率、審核修改幅度
• Day 15 的共同流程語法——七步骨架
• Day 16 的 Data Pack 六原則
• Day 19 的六類修改分類
• Day 23 的機制／政策分離
• Day 24 的文件狀態機與 Approved for Training 三條件
• Day 25 的三大鐵律
• Day 26 的保守降級判定觀與 S1–S4 分級
• Day 27 的注入測試守則
• Day 28 的風險分級矩陣與放行路線圖
• Day 29 的三層架構

需要你自己的資料才能復現：

• 訓練用的場景格式資料（但 Day 10 講了合成方法）
• 客戶脈絡（本來就該是你自己的）
• 評測的實際數字

我建議的起點：不是從 Day 1 開始照做，而是先拿 Day 6 的分流表、Day 15 的流程語法、Day 25 的三大鐵律這三樣東西，套到你自己的場景上。這三樣的投入產出比最高。

三十天教我的三件事

第一件：誠實的失敗比包裝的成功有價值

Day 12 那篇是這個系列最難寫的一篇，也是回饋最多的一篇。

如果我寫的是「經過三階段微調，模型效能提升 X%」，不提題數、不提誤差、不提另外兩組沒動——那篇會比較好看，會比較有面子，也會完全沒有價值，而且是不誠實的。

而寫出真相之後，它變成了整個系列的樞紐：Day 13 的原因分析、Day 14 的修正方案、Day 29 的三層架構，全部是從那次失敗長出來的。

在技術領域，能公開講清楚自己錯在哪的人不多。而那些內容的價值，遠高於又一篇成功案例。

第二件：知道系統不該做什麼，比知道它能做什麼重要

回頭看，這 30 天最有價值的決定，幾乎全部是「不做」：

• 不讓模型算數字（Day 15）
• 不把原始 JSON 丟給模型（Day 16）
• 不讓分類器硬歸類，沒把握就轉人（Day 18）
• 不讓模型對法規做適用性推論（Day 18）
• 不讓系統對人做能力推斷（Day 22）
• 不共用拒答邊界（Day 23）
• 不做自動處置（Day 15）
• 不在生產環境做注入測試（Day 27）
• 不把保守降級當缺陷（Day 26）

每一個「不」，都換到了一份可信任。

而 AI 系統最稀缺的資源就是信任——因為它的失敗模式是「自信地錯」，一旦失去信任，使用者就會回去手動做，系統的價值歸零。

第三件：模型會過時，判斷不會

我用的模型，一年後大概沒人會用了。訓練配方會有更好的。硬體會更便宜。

但這 30 天裡真正花力氣想清楚的東西——什麼該交給程式、什麼該交給檢索、什麼該交給模型、什麼必須交給人——這些判斷不會過時。

因為它們回答的不是「這個技術能做什麼」，而是「這件事該怎麼負責」。

而後者，是資安這個行業一直在回答的問題。AI 只是換了一個新的形式來問它。

收尾

三十天，四個部分：

• 第一部教會我：先定義問題，再選工具
• 第二部教會我：失敗要誠實地量，才會變成知識
• 第三部教會我：把系統不該做的事，一件件交給對的人或程式
• 第四部教會我：治理不是技術的附屬品，它是系統的骨架

如果只能留一句話給讀到這裡的人：

不要問「AI 能不能做這件事」，問「這件事出錯的時候，誰負責」。 這個問題的答案，會告訴你系統該怎麼設計。

謝謝陪我走完這三十天。

🛡️ Instagram： @aid3fend — AI 資安實戰紀錄，歡迎追蹤交流。